On 16/04/2013, at 1:49 PM, Wim Lewis wrote: > On 4/15/13 3:51 AM, john skaller wrote: >> Just a note on this one: I recently *removed* ssize. >> The reason is: it seems it is not standard C or C++ for any version. >> Rather, it is standard Posix. > > Ah, I didn't know that.
Meaning .. it's not available on Windows necessarily. > > I think ssize_t or the equivalent is necessary if you want to be able to > call APIs modeled on read()/write() though --- they have to return a > signed type (so that they can return -1 to indicate error). That's why I > (re-)added it, at any rate. Actually they don't. C++ uses size_t for positions. It uses npos = size_t(-1) for "error". > > Maybe the type should live in (eg) lib/std/posix/types.flx instead? It > could declare many of the POSIX types: > http://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/types.h.html Then you could only use it on a Posix platform ;( This all gets down to a very difficult modelling problem. Originally, Felix used aliases where C did. However that lead to all sorts of problems. Stuff would work on say a 64 bit system but fail on a 32 bit one. For the same reason it would screw up in C. <rant> See the disaster causes by unix bigots who sneered at lowly DOS programmers stuck with 16 bits when they had 32 bits .. and the total mess they created by not following Standards or proper practices regarding sizes. Just about every open source code in existence broke. DOS and Windows programmers knew better. They'd been dealing with size issues for ages. </rant> So I changed the core modelling to use distinct abstract types. But now you need explicit casts or conversions everywhere, which you wouldn't in C. And you need precise literals and you have to define conversions. Luckily some of the pain: len - 1uz // unsigned size_t is alleviated by the new "dot is reverse application" feature: len - 1.size is more readable and easier to remember. > > (Thinking about it, ssize_t is really an option type: Success of size_t > | Failure. Maybe Felix could support option types which map to integer > ranges somehow, like it supports ones which map to {pointer or NULL}... > at the other extreme, you'd have an enum type.) See lib/std/strings/string.fdoc, the C++ find function have two variants, one uses "npos" like in C++, and one using an option type. This is a mess. Similarly, some Posix functions are modelled on the C function exactly. And some Posix functions use a more "felix like" interface. Again, this is a mess. There really should be a 1-1 raw interface built, and a more friendly one on top of that. i started doing that: misc/posix_out.txt but my automation only handles functions, not types. > >> And a comment: I find the collection of C types and typedefs >> very confusing. For example why do we have >> >> size_t >> uintptr_t >> >> ?? For the life of me I cannot see how these types could be anything but >> equivalent: > > I've run into a couple of kinds of systems where they can be > different--- if your memory is segmented (like ancient x86 machines, or > some weird architectures with MMU-based per-object capability schemes) > and the maximum size of an object is much smaller than the total memory > addressible; or if you have multiple address spaces (a la Harvard > architectures) and need extra space in the uintptr_t to indicate the > address space. > > I don't think there's much of a risk of encountering those systems by > accident, though. It's probably not worth worrying too much about > supporting them. :) I don't think such systems are compliant (not sure). Google, btw, says "int" must be used for all sizes (Google standard). -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
