[yast-devel] Review Request (yast2-core)
Hi,
I noticed that YaST prints garbage when the logfile cannot be
opened. The problem is that strerror_r may leave buf untouched so
you have to print the returned pointer (when using the GNU
version of strerror_r).
ciao Arvin
--
Arvin Schnell,
On Tue, 8 May 2012 17:29:24 +0200
Arvin Schnell
Hi,
I noticed that YaST prints garbage when the logfile cannot be opened. The problem is that strerror_r may leave buf untouched so you have to print the returned pointer (when using the GNU version of strerror_r).
ciao Arvin
Hi, patch looks fine. Just I am curious if there is agreement that yast code is GNU specific. If we want more portable code ( for whatever reason ) maybe it will be better to just undef _GNU_SOURCE there. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, May 09, 2012 at 10:20:44AM +0200, Josef Reidinger wrote:
On Tue, 8 May 2012 17:29:24 +0200 Arvin Schnell
wrote: Hi,
I noticed that YaST prints garbage when the logfile cannot be opened. The problem is that strerror_r may leave buf untouched so you have to print the returned pointer (when using the GNU version of strerror_r).
ciao Arvin
Hi,
patch looks fine. Just I am curious if there is agreement that yast code is GNU specific. If we want more portable code ( for whatever reason ) maybe it will be better to just undef _GNU_SOURCE there.
Well, currently several GNU specific functions are used
(e.g. asprintf, basename, canonicalize_file_name). Apart from
that g++ already defines _GNU_SOURCE so making sure that no GNU
specific functions are used is not easy or maybe even impossible
(without another compiler).
Also see:
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined
ciao Arvin
--
Arvin Schnell,
On Thu, 10 May 2012 16:05:49 +0200
Arvin Schnell
On Wed, May 09, 2012 at 10:20:44AM +0200, Josef Reidinger wrote:
On Tue, 8 May 2012 17:29:24 +0200 Arvin Schnell
wrote: Hi,
I noticed that YaST prints garbage when the logfile cannot be opened. The problem is that strerror_r may leave buf untouched so you have to print the returned pointer (when using the GNU version of strerror_r).
ciao Arvin
Hi,
patch looks fine. Just I am curious if there is agreement that yast code is GNU specific. If we want more portable code ( for whatever reason ) maybe it will be better to just undef _GNU_SOURCE there.
Well, currently several GNU specific functions are used (e.g. asprintf, basename, canonicalize_file_name). Apart from that g++ already defines _GNU_SOURCE so making sure that no GNU specific functions are used is not easy or maybe even impossible (without another compiler).
Also see:
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined
ciao Arvin
Hi, what comes to my mind is potential usage of icc or llvm for compilation, where we can have problems. If we really want GNU version we should ensure, that it is used with preprocessor magic. Example is e.g. in this header file with defining and undefining GNU_SOURCE - http://clang.llvm.org/doxygen/unwind_8h_source.html So question is if we want be prepared for different compiler and different libc ( like uclibc or dietlibc ). But quick research show that uclibc with proper directory can use gnu extension and dietlibc start having some gnu extensions, so maybe it is not so big issue. I just think that we should explicitelly state this somewhere to avoid surprise. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
Arvin Schnell
-
Josef Reidinger