[vdr] Re: [PATCH] fix segfaults because of channels with umlauts

[Ludwig Nussel <ludwig.nussel@gmx.de>]

Klaus Schmidinger wrote:
> Klaus Schmidinger wrote:
> > 
> > Ludwig Nussel wrote:
> > >
> > > Nevertheless it's a bug in vdr to ignore the
> > > return value and to not check for NULL. Attached patch is for 1.2.6,
> > > 1.3.x needs a similar one.
> > 
> > I guess you're right about checking the return value of asprintf().
> > But first I'd like to know exactly why asprintf() failed on your system.
> > The typical error mentioned in the GNU C Library Reference Manual for
> > asprintf() would be a failure to allocate the buffer, which normally
> > should be pretty unlikely, given the amount of RAM today's systems have...
> 
> I've decided against checking all the return values of asprintf(), because
> that would be too much hassle in many places. Besides, there are many places
> where objects are allocated on the heap and it is not explicitly checked
> whether the returned pointer is valid. At some point one must be able to
> assume that there is enough memory available, otherwise the whole system
> wouldn't be able to work reasonably at all.

The problem here is not failure to allocate memory but as the
manpage says 'some other error'. Invalid UTF-8 strings are probably
just one example of 'some other error'. Ignoring that leads to
strange crashes. The quick workaround I posted does just #define
asprintf to something that sets the pointer to NULL in case of
failure. If vdr then crashes because of a NULL pointer it's clearly
a bug and easy to debug. Instead of the #define it would also be
possible to write a real function with a different name as wrapper
to asprintf or to put the wrapper into a different namespace like
vdr::asprintf and substitute all asprintf with that.

> The actual problem here doesn't even have to do with memory consumption,
> but rather with incompatible character representations, which would cause
> the program to work wrong, anyway. So I'd rather remove the root of all evil,
> which is UTF-8. I'll therefore add a few lines to vdr.c, which will check
> this at program startup and exit if necessary:

That's nasty, better downgrade it to a warning. A proper fix would
be to convert all incoming strings to the encoding vdr runs in
(which ideally would be UTF-8 to be able to handle all languages).
Btw, right now vdr creates invalid directories in /video when the
system locale is UTF-8 which means that e.g. gtk2 programs don't
display them in the file selection dialog.

cu
Ludwig

-- 
(o_  Ludwig.Nussel@gmx.de
//\  PGP Key ID: FF8135CE
V_/_ ICQ:        52166811