Re: rename functions as they conflict with glibc

Bill Davidsen <[email protected]>
Newsgroups gmane.comp.audio.cd-record
Organization TMR Associates Inc, Schenectady NY
Message-ID <[email protected]>
Joerg Schilling wrote:
> Roman Rakus <[email protected]> wrote:
>
>   
>> I'm not sure if this problem is also fixed but this patch rename 
>> functions as they conflict with glibc.
>>     
>
> Your mail addresses two problems:
>
> The problem is that POSIX.1-2008 is in conflict with general rules in POSIX.
> POSIX as well as glibc illegally uses these names: POSIX grants that it will 
> never break published older code. The POSIX standard for this reason was not
> allowed to use these names. The Standard Commitee has even been informed about
> the problem to no avail.
>
> Note that the names in question are in widely spread public use since 1982 with 
> the interfaces used by libschily. So glibc is introducing a non-compliance 
> because the functions using the same names in glibc implement different 
> interfaces. 
>
>   
I'm sad that you are still beating this dead horse. You waste your time 
and energy debating an issue long since settled. It no longer matters if 
you are right, neither POSIX nor the millions of applications using 
POSIX definitions are going to change. You are taking the policy on 
breaking existing programs using older POSIX compliant libraries, and 
trying to convince them that it applies to applications written against 
other libraries using the same names.

Einstein is credited with saying that the definition of stupidity (some 
claim he said futility) is doing the same thing over and over hoping for 
a different result.

> Your problem is a result of using _extremely_ outdated and even illegal (*) 
> sources from a questionable fork. 
>
> *) illegal because in 2006, the initators of the fork introduced modifications 
> that are in conflict with the Copyright law. The code you send cannot be legally 
> distributed.
>
>   
You should get a lawyer or get a life. Why do you fritter away your time 
revisiting this issue?
> I recommend you to just upgrade to recent original code. Original code is 
> legally distributable and it does implement a workaround for the problem since 
> the non-POSIX compliant ;-) POSIX.1-2008 has been approved in Summer 2008.
>
>
> Here is the recent original code:
>
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> Please upgrade all related code at RedHat's site as soon as possible and stop 
> publishing the code you are currently distributing.
>   

Redhat and other gave up your version because you were too difficult to 
work with. Since your willingness to accept other views as having merit 
hasn't changed, neither will the decision to use a hack on you old code. 
The problem is of your making.

-- 
Bill Davidsen <[email protected]>
  Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one error occurs during
wildcard (glob) expansion.


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.