[uClibc] [PATCH] remove spaces escaping in getmntent

[Aurelien Jacobs]

On 7/15/2004, "Erik Andersen" <andersen at codepoet.org> wrote:

>On Wed Jul 07, 2004 at 11:58:59PM +0200, Aurelien Jacobs wrote:
>> Hi,
>>
>> I encounterd a problem, using the mount command with uClibc.
>> I have some mountpoints containing spaces. The kernel replace
>> space by \040 in the /proc/mounts file and so the getmntent
>> function should replace those \040 by spaces.
>> That's what my patch does. The decode_name function come from
>> the glibc.
>>
>> I hope this is acceptable for inclusion.
>
>Wouldn't it be cleaner to process 'buff' for "\040" just once,
>prior to the first call to strtok_r?

No ! This is the point of those "\040" !
If you process buff before the call to strtok_r there will be spaces
in the mountpoint name and strtok_r will split in the middle of
this name !

>More importantly, I do not see any other C library doing any such
>decoding

Doesn't the glibc count as a C library ? ;-)
A simple program listing mounted partitions always works well with
the glibc, and will seem to work well with the uClibc until there
is a mountpoint containing spaces.
This can easily lead to hard to find bugs (I know what I say ;-).

>and in fact, I _do_ see the encoded values being entered
>into i.e. /etc/mtab by mount from util-linux

Sure ! This is what allow scripts or C library to split the fields.
The space character is used as a field separator so the mountpoint
can't contain spaces in /etc/mtab or /proc/mounts.
The C library return the fields in separted strings, so they can
(and should ?) contain spaces.

>so I do not think that changing mntent() is the Right Thing(tm).

I would assume that if glibc does it, this is the Right Thing(tm),
but maybe I'm wrong. As this function is not POSIX, nor ANSI, I
didn't found any description of how it should behave exactly,
and especially on this specific point.

>If anything, application code that cannot cope should probably
>be adapted.

You would suggest to duplicate this code in every program dealing
with mntent ? This is not really space efficient ;-)

Aurel