Josselin Mouette writes:
> Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit :
>> Trusting a library to do all your error handling and cleanup is not
>> good style IMHO. In addition to the lack of self-documenting source,
>> it often leave you with the meaningless generic error messa
Josselin Mouette wrote:
Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit :
Trusting a library to do all your error handling and cleanup is not good
style IMHO. In addition to the lack of self-documenting source, it
often leave you with the meaningless generic error messages some OSe
On Tue, Sep 08, 2009 at 01:16:08PM +0200, Josselin Mouette wrote:
> Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit :
> > Trusting a library to do all your error handling and cleanup is not good
> > style IMHO. In addition to the lack of self-documenting source, it
> > often leave yo
Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit :
> Trusting a library to do all your error handling and cleanup is not good
> style IMHO. In addition to the lack of self-documenting source, it
> often leave you with the meaningless generic error messages some OSes
> are so full of.
Josselin Mouette writes:
> Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a
> écrit :
>> Steve Langasek wrote:
>> > Case 1, please. Either case 2 fails to handle the allocation error, or
>> > glib
>> > is doing its own abort. Neither is acceptable.
>
> Yeah, sure. As if there w
* Josselin Mouette [090908 11:00]:
> Le mardi 08 septembre 2009 à 10:55 +0200, Bernhard R. Link a écrit :
> > Often there is something sensible: Wait till more memory is available or
> > just make the operation needing so much memory fail.
>
> If it???s an operation that specifically requires muc
Twas brillig at 11:00:07 08.09.2009 UTC+02 when j...@debian.org did gyre and
gimble:
JM> If it’s an operation that specifically requires much memory, Glib
JM> provides g_try_*alloc functions for that.
JM> However, when allocations start failing for string manipulation
JM> operations, the ap
* Josselin Mouette , 2009-09-08, 10:06:
> Case 1, please. Either case 2 fails to handle the allocation error, or glib
> is doing its own abort. Neither is acceptable.
Yeah, sure. As if there was anything more sensible to do than aborting
when a memory allocation fails. When this happens under
Le mardi 08 septembre 2009 à 10:55 +0200, Bernhard R. Link a écrit :
> Often there is something sensible: Wait till more memory is available or
> just make the operation needing so much memory fail.
If it’s an operation that specifically requires much memory, Glib
provides g_try_*alloc functions
* Josselin Mouette [090908 10:45]:
> Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a
> > Steve Langasek wrote:
> > > Case 1, please. Either case 2 fails to handle the allocation error, or
> > > glib
> > > is doing its own abort. Neither is acceptable.
>
> Yeah, sure. As if ther
Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a
écrit :
> Steve Langasek wrote:
> > Case 1, please. Either case 2 fails to handle the allocation error, or glib
> > is doing its own abort. Neither is acceptable.
Yeah, sure. As if there was anything more sensible to do than abort
Giacomo A. Catenazzi wrote:
> >>Case 2:
> >>char *foo = g_strdup_printf ("%s equals %i", somestring,
> >>someint);
> >
> >>Pick your choice.
> >
> >Case 1, please. Either case 2 fails to handle the allocation error, or glib
> >is doing its own abort. Neither is acceptable.
> >
>
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
> Case 1:
> char *foo;
> if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
> fprintf(stderr, "Failed to allocate memory");
> abort();
> }
>
> Case 2:
> ch
On Mon, Sep 07, 2009 at 03:51:54PM +0200, Bjørn Mork wrote:
> Do you really need the g_utf16_to_utf8 unicode translation? You could
> just as well let udev export the raw utf16 value and leave the
> conversion up to the users. They may want something different than utf8
> anyway.
man 3 iconv
--
Steve Langasek wrote:
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.
Case 1:
char *foo;
if (aspri
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
> > For the record: Noone sane would replace g_strdup_printf with snprintf,
> > but with asprintf.
> Case 1:
> char *foo;
> if (asprintf(&foo, "
Le lundi 07 septembre 2009 à 17:32 +0200, Mike Hommey a écrit :
> Nobody has advised to strip them down from the library. Just to stop
> using glib in a small udev binary that only uses glib wrappers.
And I still believe this advice is wrong.
--
.''`. Josselin Mouette
: :' :
`. `' “I re
On Mon, Sep 07, 2009 at 05:15:44PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit :
> > So no trying to convince glib upstream to reduce wrapper bloat? *sigh*
>
> What you are calling wrapper bloat is critical for portability of many
> applicati
Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit :
> So no trying to convince glib upstream to reduce wrapper bloat? *sigh*
What you are calling wrapper bloat is critical for portability of many
applications, since it behaves the same on all systems where Glib has
been ported. Ju
Zitat von Josselin Mouette :
Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit :
I'm suggesting that the utility uses lots of "g_" prefixed functions
while it's obvious that the author never ever evaluated the need for
these. I assume that's because the author is used to them always
Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit :
> I'm suggesting that the utility uses lots of "g_" prefixed functions
> while it's obvious that the author never ever evaluated the need for
> these. I assume that's because the author is used to them always being
> available.
>
> W
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
> For the record: Noone sane would replace g_strdup_printf with snprintf,
> but with asprintf.
Case 1:
char *foo;
if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
fprintf(stderr, "Fa
Josselin Mouette writes:
> Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit :
>> You're not seriously suggesting that DeviceKit-disks usage of g_print
>> instead of printf is actually adding anything useful?
>
> Yeah sure, just look at g_print and not at the other symbols used by
> de
Zitat von Josselin Mouette :
Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
It rather needs to raise the question why simple low-level tools
use something
like libglib?
I’d rather raise the question why each of our simple low-level tools
implement its data structure
* Josselin Mouette [090907 12:37]:
> Are you suggesting that such an utility should implement its own linked
> list structure, and unicode translation functions? Are you aware of the
> security implications of using snprintf instead of g_strdup_printf?
For the record: Noone sane would replace g_s
Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit :
> You're not seriously suggesting that DeviceKit-disks usage of g_print
> instead of printf is actually adding anything useful?
Yeah sure, just look at g_print and not at the other symbols used by
devkit-disks-part-id :
g_free g_slist
Josselin Mouette writes:
> Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
>> It rather needs to raise the question why simple low-level tools use
>> something
>> like libglib?
>
> I’d rather raise the question why each of our simple low-level tools
> implement its data s
Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
> It rather needs to raise the question why simple low-level tools use
> something
> like libglib?
I’d rather raise the question why each of our simple low-level tools
implement its data structures and basic routines in its
Hendrik Sattler wrote:
>> (I'll do you one better, though -- system-config-printer upstream wants to
>> install /lib/udev/udev-configure-printer, which pulls in the entire libcups
>> stack. Sigh...)
>
> *sigh* I agree. Has the world gone mad?
The desktop world, yes.
JB.
--
Julien BLACHE - D
On Sep 06, Hendrik Sattler wrote:
> And what about embedded systems? They start to use those libraries for even
> the simplest utilities that are also usuable on very small systems. And
> that's
No, "they" do not.
--
ciao,
Marco
signature.asc
Description: Digital signature
Am Samstag 05 September 2009 23:29:39 schrieb Steve Langasek:
> The rationale for this /using glib/ is that devicekit-disks is not an
> integral part of udev, it's an add-on component that will be installed only
> on desktop systems. So the size impact to /lib for servers for this
> component woul
On Sep 05, Goswin von Brederlow wrote:
> It is my understanding that the events get triggered in/before the
> initramfs and need to be replayed after switching to / already.
> How is replaying them when entering runlevel 2 any different from
> that?
The main issue is that the rules which run in t
On Sat, Sep 05, 2009 at 11:02:51AM +0200, Hendrik Sattler wrote:
> Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
> > On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> > > And it is also very unclear to me why this has to be in /lib/udev at
> > > all.
> > Because it prov
Michael Biebl writes:
> Gabor Gombas wrote:
>> On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote:
>>
>>> For your proposal to work, you'd need some kind of replay mechanism, which
>>> allows udev to replay the add/remove events when /usr is available the
>>> extended
>>> ruleset is
Am Samstag 05 September 2009 11:20:06 schrieb Michael Biebl:
> Hendrik Sattler wrote:
> > Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
> >> On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> >>> And it is also very unclear to me why this has to be in /lib/udev at
> >>> a
Hendrik Sattler wrote:
> "This is the interface almost everything is going to turn to with GNOME
> 2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
> time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
> HAL."
> and
> "all current DeviceKit-{power,disks} vers
Hendrik Sattler wrote:
> Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
>> On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
>>> And it is also very unclear to me why this has to be in /lib/udev at
>>> all.
>> Because it provides a single point where the desktop hooks into
Gabor Gombas wrote:
> On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote:
>
>> For your proposal to work, you'd need some kind of replay mechanism, which
>> allows udev to replay the add/remove events when /usr is available the
>> extended
>> ruleset is activated.
>
> You mean "udevad
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
> On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> > And it is also very unclear to me why this has to be in /lib/udev at
> > all.
>
> Because it provides a single point where the desktop hooks into the kernel
> hotplug eve
On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote:
> For your proposal to work, you'd need some kind of replay mechanism, which
> allows udev to replay the add/remove events when /usr is available the
> extended
> ruleset is activated.
You mean "udevadm trigger"?
Gabor
--
---
On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> And it is also very unclear to me why this has to be in /lib/udev at
> all.
Because it provides a single point where the desktop hooks into the kernel
hotplug event system, instead of having hal redo all the work already done
by udev.
Hendrik Sattler writes:
> Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
>> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
>> libraries which are (currently) in /usr/lib, i.e.
>> devkit-disks-part-id links against libglib-2.0 (784K)
>> devkit-disks-probe-ata-
Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
> libraries which are (currently) in /usr/lib, i.e.
> devkit-disks-part-id links against libglib-2.0 (784K)
> devkit-disks-probe-ata-smart links against (48K)
>
>
Gabor Gombas wrote:
>
> IMHO this looks more and more like the udev rules has to be split into
> at least two categories:
>
> - a basic set that is used during boot and early system setup. Services
> in rcS.d are allowed to rely on these rules only, and these rules must
> not rely on anything
On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote:
> I'd like to add here, that devicekit-disks will install udev helpers
> /lib/udev/devkit-disks-* which are called in
> /lib/udev/rules.d/95-devkit-disks.rules.
>
> devkit-disks-part-id and devkit-disks-probe-ata-smart both link again
Package: devicekit-disks
Severity: serious
On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote:
> I'd like to add here, that devicekit-disks will install udev helpers
> /lib/udev/devkit-disks-* which are called in
> /lib/udev/rules.d/95-devkit-disks.rules.
>
> devkit-disks-part-id and d
Marco d'Itri wrote:
> On Sep 04, Steve Langasek wrote:
>
>> I still can't fathom why someone decided that udev should be responsible for
>> translating PCI IDs and USB IDs into text strings. This smells of crazy.
> I think that part of the rationale is that eventually HAL will go away
> replaced
47 matches
Mail list logo
