It should be compatible. The spinlock members are now in what were dummy slots in the CSOUND structure.

Regards,
Mike

-----Original Message-----
>From: Felipe Sateler 
>Sent: Sep 21, 2008 7:25 PM
>To: Developer discussions 
>Subject: Re: [Cs-dev] Recent changes break API compatibility?
>
>What's the status on this for 5.09?
>
>
>El 09/09/08 02:20 Anthony Kozar escribió:
>> I am just looking through various changes over the past few months and I
>> noticed a number of things that make me wonder if API compatibility is
>> being preserved.
>>
>> Most recently, two new variables, spoutlock and spinlock, were added to the
>> middle of the public section of the CSOUND struct:
>>
>>     int    ksmps, global_ksmps, nchnls, spoutactive, spoutlock, spinlock;
>>
>> Also, I am wondering what the size of a long is on 64-bit architectures?
>> With all of the changes of short to int16 and long to int32, the signatures
>> for several of the function pointers in the CSOUND struct have changed.  If
>> long is 64 bits wide on some architectures, this change is a problem.  A
>> few public data structures may have been changed this way also.
>>
>> One other subtle type change is the following:
>>
>>     void (*AuxAlloc)(CSOUND *, long nbytes, AUXCH *auxchp);
>>     void (*AuxAlloc)(CSOUND *, size_t nbytes, AUXCH *auxchp);
>>
>>   typedef struct auxch {
>>     struct auxch *nxtchp;
>>     long    size;
>>     void    *auxp, *endp;   /* was char* */
>>   } AUXCH;
>>
>>   typedef struct auxch {
>>     struct auxch *nxtchp;
>>     size_t  size;
>>     void    *auxp, *endp;
>>   } AUXCH;
>>
>> At least on my system, long and size_t are not the same.  size_t is an
>> unsigned long.  I suppose that this will not cause any problems unless an
>> AUXCH has a size greater than MAX_LONG or if there is a bigger difference
>> between these two types on some other architecture.
>>
>>
>> Anthony Kozar
>> mailing-lists-1001 AT anthonykozar DOT net
>> http://anthonykozar.net/
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge Build the coolest Linux based applications with Moblin SDK & win
>> great prizes Grand prize is a trip for two to an Open Source event anywhere
>> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>Saludos,
>Felipe Sateler




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/l

Yes, the spinlock members look good now.  The API subversion number should
have been increased though.  Oh well ...

However, I still think that compatibility may have been broken on the x86-64
architecture.  The following information from the GCC manual suggests that
the changing of 'long' to 'int32' in csoundCore.h will have changed some
struct members and some function parameters from 64-bit to 32-bit integers:

    -m32 
    -m64 
    
    Generate code for a 32-bit or 64-bit environment. The 32-bit environment
    sets int, long and pointer to 32 bits and generates code that runs on
    any i386 system. The 64-bit environment sets int to 32 bits and long and
    pointer to 64 bits and generates code for AMD's x86-64 architecture.

I do not see -m64 being explicitly invoked in SConstruct but I would assume
that using a 64-bit toolchain on an x86-64 machine implies this compiler
option.

I am not saying that changing 'long' to 'int32' was the wrong choice.  The
previous situation of having certain data structures use 32-bit longs on
some machines and 64-bit longs on others may have had undesirable
consequences for some of Csound's file formats.  But, we should all be aware
of the consequences of changing the API/ABI without changing the API major
version number and should consider documenting these changes.

Perhaps it would be best to consider the 64-bit version of Csound's API to
have been "immature" or "under-tested" before 5.09 with the new changes
representing "fixes".

I'd like to hear more about why the 'long' to 'int32' changes were made and
how we are to view these changes.

Anthony

Michael Gogins wrote on 9/22/08 9:09 AM:

> It should be compatible. The spinlock members are now in what were dummy
> slots in the CSOUND structure.
> 
> Regards,
> Mike
> 
> -----Original Message-----
>> From: Felipe Sateler 
>> Sent: Sep 21, 2008 7:25 PM
>> To: Developer discussions 
>> Subject: Re: [Cs-dev] Recent changes break API compatibility?
>> 
>> What's the status on this for 5.09?
>> 
>> 
>> El 09/09/08 02:20 Anthony Kozar escribió:
>>> I am just looking through various changes over the past few months and I
>>> noticed a number of things that make me wonder if API compatibility is
>>> being preserved.
>>> 
>>> Most recently, two new variables, spoutlock and spinlock, were added to the
>>> middle of the public section of the CSOUND struct:
>>> 
>>> int    ksmps, global_ksmps, nchnls, spoutactive, spoutlock, spinlock;
>>> 
>>> Also, I am wondering what the size of a long is on 64-bit architectures?
>>> With all of the changes of short to int16 and long to int32, the signatures
>>> for several of the function pointers in the CSOUND struct have changed.  If
>>> long is 64 bits wide on some architectures, this change is a problem.  A
>>> few public data structures may have been changed this way also.
>>> 
>>> One other subtle type change is the following:
>>> 
>>> void (*AuxAlloc)(CSOUND *, long nbytes, AUXCH *auxchp);
>>> void (*AuxAlloc)(CSOUND *, size_t nbytes, AUXCH *auxchp);
>>> 
>>> typedef struct auxch {
>>> struct auxch *nxtchp;
>>> long    size;
>>> void    *auxp, *endp;   /* was char* */
>>> } AUXCH;
>>> 
>>> typedef struct auxch {
>>> struct auxch *nxtchp;
>>> size_t  size;
>>> void    *auxp, *endp;
>>> } AUXCH;
>>> 
>>> At least on my system, long and size_t are not the same.  size_t is an
>>> unsigned long.  I suppose that this will not cause any problems unless an
>>> AUXCH has a size greater than MAX_LONG or if there is a bigger difference
>>> between these two types on some other architecture.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Felipe, 

A few quick notes as I do not have a lot of time but I will be gone for a
week or more starting tomorrow ...

I have not been distinguishing between API, ABI, and host versus plugin
compatbility -- it is easier to just call it all the "API".  I think (but am
not sure) that most of the changes are problems for plugin compatibility.
We should be concerned that private opcode libraries (I have some) or opcode
libraries that the Csound dev team no longer supports (eg. Loris ops)
continue to work with new versions of Csound without the need for
recompilation.

I suspect that some of the structs in csoundCore.h may in fact be used by
the host API as well -- the FUNC struct is one that comes to mind -- but I
don't have the time to audit the situation right now.  The EVTBLK struct is
tied to Cscore as well.

I raised the issue about incompatibilities introduced with the SDFT code but
no one else seemed to care.  I still compile Mac OS 9 Csound without SDFT
for this reason.

Anthony
  
Felipe Sateler wrote on 9/25/08 12:24 PM:

> Sorry for making the discussion slow, but I've been busy.
> 
> As I understand, csoundCore.h is not meant to be included by host
> applications. As such, any structures defined there should (please correct me
> if it's not the case) be treated as obscure types for those applications, if
> used at all. This means that the ABI has not changed, even if the structs
> have changed, because they are only manipulated inside the library.
> OTOH, plugins are supposed to include csoundCore.h. Thus, external plugins may
> be affected by this change.
> 
> However, there are the same kind of changes inside csound.h (and plenty other
> headers), which is supposed to be included by applications.[1] This will
> break them on 64bit if they access the structs directly. The ABI should have
> been increased. However, if the applications only use the API functions, then
> the ABI has not changed, because the structures are obscure types for them.
> Is there any reason for an application developer to access the structures
> directly? The structures are undocumented, so I would guess that they aren't
> meant to be used by application developers. If so, I would suggest moving the
> structures to csoundCore.h (or even better, some of these structs seem
> plugin-specific, they should be moved to a plugin-specific header).
> 
> 
> 
> [1] I also see other stuff that's not good. For example, building with SDFT
> changes the ABI too by adding members to the middle of a struct.
> 
> El 22/09/08 12:16 Anthony Kozar escribió:
>> Yes, the spinlock members look good now.  The API subversion number should
>> have been increased though.  Oh well ...
>> 
>> However, I still think that compatibility may have been broken on the
>> x86-64 architecture.  The following information from the GCC manual
>> suggests that the changing of 'long' to 'int32' in csoundCore.h will have
>> changed some struct members and some function parameters from 64-bit to
>> 32-bit integers:
>> 
>> -m32
>> -m64
>> 
>> Generate code for a 32-bit or 64-bit environment. The 32-bit
>> environment sets int, long and pointer to 32 bits and generates code that
>> runs on any i386 system. The 64-bit environment sets int to 32 bits and
>> long and pointer to 64 bits and generates code for AMD's x86-64
>> architecture.
>> 
>> I do not see -m64 being explicitly invoked in SConstruct but I would assume
>> that using a 64-bit toolchain on an x86-64 machine implies this compiler
>> option.
>> 
>> I am not saying that changing 'long' to 'int32' was the wrong choice.  The
>> previous situation of having certain data structures use 32-bit longs on
>> some machines and 64-bit longs on others may have had undesirable
>> consequences for some of Csound's file formats.  But, we should all be
>> aware of the consequences of changing the API/ABI without changing the API
>> major version number and should consider documenting these changes.
>> 
>> Perhaps it would be best to consider the 64-bit version of Csound's API to
>> have been "immature" or "under-tested" before 5.09 with the new changes
>> representing "fixes".
>> 
>> I'd like to hear more about why the 'long' to 'int32' changes were made and
>> how we are to view these changes.
>> 
>> Anthony
>> 
>> Michael Gogins wrote on 9/22/08 9:09 AM:
>>> It should be compatible. The spinlock members are now in what were dummy
>>> slots in the CSOUND structure.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> -----Original Message-----
>>> 
>>>> From: Felipe Sateler 
>>>> Sent: Sep 21, 2008 7:25 PM
>>>> To: Developer discussions 
>>>> Subject: Re: [Cs-dev] Recent changes break API compatibility?
>>>> 
>>>> What's the status on this for 5.09?
>>>> 
>>>> El 09/09/08 02:20 Anthony Kozar escribió:
>>>>> I am just looking through various changes over the past few months and
>>>>> I noticed a number of things that make me wonder if API compatibility
>>>>> is being preserved.
>>>>> 
>>>>> Most recently, two new variables, spoutlock and spinlock, were added to
>>>>> the middle of the public section of the CSOUND struct:
>>>>> 
>>>>> int    ksmps, global_ksmps, nchnls, spoutactive, spoutlock, spinlock;
>>>>> 
>>>>> Also, I am wondering what the size of a long is on 64-bit
>>>>> architectures? With all of the changes of short to int16 and long to
>>>>> int32, the signatures for several of the function pointers in the
>>>>> CSOUND struct have changed.  If long is 64 bits wide on some
>>>>> architectures, this change is a problem.  A few public data structures
>>>>> may have been changed this way also.
>>>>> 
>>>>> One other subtle type change is the following:
>>>>> 
>>>>> void (*AuxAlloc)(CSOUND *, long nbytes, AUXCH *auxchp);
>>>>> void (*AuxAlloc)(CSOUND *, size_t nbytes, AUXCH *auxchp);
>>>>> 
>>>>> typedef struct auxch {
>>>>> struct auxch *nxtchp;
>>>>> long    size;
>>>>> void    *auxp, *endp;   /* was char* */
>>>>> } AUXCH;
>>>>> 
>>>>> typedef struct auxch {
>>>>> struct auxch *nxtchp;
>>>>> size_t  size;
>>>>> void    *auxp, *endp;
>>>>> } AUXCH;
>>>>> 
>>>>> At least on my system, long and size_t are not the same.  size_t is an
>>>>> unsigned long.  I suppose that this will not cause any problems unless
>>>>> an AUXCH has a size greater than MAX_LONG or if there is a bigger
>>>>> difference between these two types on some other architecture.
>> 
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge Build the coolest Linux based applications with Moblin SDK & win
>> great prizes Grand prize is a trip for two to an Open Source event anywhere
>> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> Saludos,
> Felipe Sateler
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sorry Felipe, but I don't really know what you should do.  One possibility
would be for you to increase the API version number for Debian now and we
can either increase in the Sourceforge packages in the next release or the
next time there is an incompatible change.  If the latter, then the
"canonical" API version could increase to "3.0" simultaneously with Debian
Csound's, skipping "2.x" since Debian would already be using those
numbers.

*shrug*

What do other developers think about this whole situation in general?

Anthony

On Sun, September 28, 2008 1:21 pm, Felipe Sateler wrote:
> I think the API version number should have been bumped. Breakage will
> happen,
> at least on 64bit archs, and on other archs for the SDFT code if plugins
> were
> compiled for pre-SDFT csound.
>
> I don't really know what to do for the debian packages now. I don't want
> to
> introduce a Debian-specific version bump, but I can't really just ignore
> the
> fact that two ABI-incompatible libraries have the same SONAME.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net