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.
and BTW the function
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 j...@debian.org, 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
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 aborting
* Josselin Mouette j...@debian.org [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
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
* Josselin Mouette j...@debian.org [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
Josselin Mouette j...@debian.org 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
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 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
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 you with
Josselin Mouette j...@debian.org 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
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
Josselin Mouette j...@debian.org 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
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
* Josselin Mouette j...@debian.org [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
Zitat von Josselin Mouette j...@debian.org:
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
Josselin Mouette j...@debian.org 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
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, Failed
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.
Well, in
Zitat von Josselin Mouette j...@debian.org:
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
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.
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
applications,
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
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, %s equals
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
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
--
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:
char *foo =
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 would
On Sep 06, Hendrik Sattler p...@hendrik-sattler.de 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
Hendrik Sattler p...@hendrik-sattler.de 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.
--
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.
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
--
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 event
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 udevadm trigger?
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 the kernel
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} versions
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
all.
Michael Biebl bi...@debian.org 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
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 provides a
On Sep 05, Goswin von Brederlow goswin-...@web.de 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
Marco d'Itri wrote:
On Sep 04, Steve Langasek vor...@debian.org 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
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
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 against
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
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)
This
Hendrik Sattler p...@hendrik-sattler.de 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)
47 matches
Mail list logo
