chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] use consistent naming for allocating unsaf


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] use consistent naming for allocating unsafe SRFI-4 accessors
Date: Thu, 23 Feb 2012 21:26:43 +0100
User-agent: Mutt/1.4.2.3i

On Tue, Feb 21, 2012 at 11:25:30AM +0100, Felix wrote:
> The attached patch changes some internal SRFI-4 accessors to use the
> correct naming scheme ("C_a_u_i_..." for allocating, unsafe inline 
> functions). Also, a bug in the length-check for "f64vector-ref" is
> fixed.

Shouldn't this be a CR, or at least keep around the old names for
one release, in deprecated state?

I don't know how "official" the C api is, but possibly people are
relying on these macros.

By the way, speaking of deprecations, now that we have deprecation
warnings from the scrutinizer, we should probably also add them for
C functions and perhaps types as well.

It turns out GCC has an "__attribute__((deprecated))", which
is also supported by CLANG.  See
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Function-Attributes.html#Function%20Attributes
and http://clang.llvm.org/docs/LanguageExtensions.html#deprecated

MSVC also has something similar:
http://msdn.microsoft.com/en-US/library/044swk7y%28v=vs.80%29.aspx

I haven't found any definite documentation, but I've seen various
mentions that Intel's compiler also support __attribute__ and __declspec
for compatibility reasons, but I don't know if it supports "deprecated".
In any case, it doesn't matter if a compiler doesn't support it, you
simply wouldn't get an error.

The attached patches might be a good start.  Try compiling the following
"program" after applying both:


(foreign-declare
  "void blabla1(void) { ___byte_vector x; printf(\"%s\\n\", x); }\n"
  "void blabla2(C_word foo) { C_hash_string(foo); }")

(u32vector-ref (u32vector 1 2 3) 0)
(s32vector-ref (s32vector 1 2 3) 0)
(f32vector-ref (f32vector 1.0 2.0 3.0) 0)
(f64vector-ref (f64vector 1.0 2.0 3.0) 0)


When I do that and compile (with -O4), I get the following messages:

test.c: In function 'blabla1':
test.c:13: warning: 'x' is deprecated (declared at test.c:13)
test.c: In function 'blabla2':
test.c:15: warning: 'C_hash_string' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:1632)
test.c: In function 'f_213':
test.c:129: warning: 'C_a_i_u32vector_ref' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:2857)
test.c: In function 'f_209':
test.c:145: warning: 'C_a_i_s32vector_ref' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:2861)
test.c: In function 'f_205':
test.c:161: warning: 'C_a_i_f32vector_ref' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:2865)
test.c: In function 'f_201':
test.c:178: warning: 'C_a_i_f64vector_ref' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:2869)


One disadvantage is that types defined with #define can't really be
deprecated easily, as you can see above.  x isn't deprecated, but the
datatype __byte_vector is!  This can be fixed if we change type
declarations to proper typedefs like so:

C_deprecated typedef unsigned char * ___byte_vector;

/* This also works:
   typedef unsigned char * ___byte_vector C_deprecated; */

then the errors start looking better:

test.c: In function 'blabla1':
test.c:13: warning: '___byte_vector' is deprecated
test.c: In function 'blabla2':
test.c:15: warning: 'C_hash_string' is deprecated (declared at 
/home/sjamaan/chicken-test/include/chicken/chicken.h:1628)

These annotations also work for struct attributes, for example,
which I think is pretty damn cool :)

By the way, is MSVC still supported at all?  I saw some reference to
it near the top of chicken.h (line 117):

#ifndef _MSC_VAR
# include <strings.h>
#endif

but otherwise, there's no trace of it.  If we don't support it, we
should rip that out.  (also, I think it's wrong since it should
really be _MSC_VER instead of _MSC_VAR, AFAIK)

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: 0001-Add-deprecation-warnings-for-deprecated-functions-an.patch
Description: Text document

Attachment: 0002-use-correct-naming-for-unsafe-allocating-XXXvector-a.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]