<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Um..I have spent quite some time reading stat.h. At least 5 minutes. :)<br><br>I must say, I really really really like the copyout method.<br><br>Obviously, it goes something like this:<br><br> struct_stat = RECORD<br> st_dev : uint64_t;<br> st_ino : uint64_t;<br> st_mode : uint64_t;<br> st_nlink : uint64_t;<br> st_uid : uint64_t;<br> st_gid : uint64_t;<br> st_rdev : uint64_t;<br> st_size : uint64_t;<br> st_blksize: uint64_t;<br> st_blocks : uint64_t;<br> st_atime : uint64_t;<br> st_mtime : uint64_t;<br> st_ctime : uint64_t;<br> END;<br> struct_stat_star = UNTRACED REF struct_stat;<br><br><br>void copyout(const stat_t* s, m3_stat_t* m)<br>{<br> m->st_ctime = s.st_stime;<br> ...<br>}<br>int m3_stat(const char* path, m3_stat_t* m)<br>{<br> int result;<br> struct stat s;<br><br> result = m3_stat(path, &s);<br> copyout(&s, m);<br> return result;<br>}<br><br>and this one type definition and wrapper function is, like, arbitrarily portable to all systems.<br>Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying.<br><br>I think I agree merging the files into Umachine.i3.<br><br>However consider the part of Ustat.i3 other than the struct.<br>The bit masks are probably identical across ALL platforms.<br>The function declarations are.<br>Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it.<br>I'd rather uint16_t, uint32_t, uint64_t.<br><br>So I think moving just the struct into its own file, or using copyout, not a bad idea.<br><br>Ustat.i3 is not quite the best example.<br>I think a much better one is Upthread.i3.<br>The file is very large and basically I think varies by 3-5 lines per variation.<br><br>Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically.<br>This work should probably be fully automated, at least for test cases, so assert the correctness.<br>You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical.<br>This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile.<br>I assert that transcribing .h files into .i3 files is a very dubious practise.<br>It has an upside of easier cross building -- don't need the platform-specific headers.<br>And it has the upside of not needing to worry about parsing .h files.<br>But it is obviously bad maintainability.<br><br>Better would be do wrappers like the above, except where perf is critical.<br>Or at least actively (daily) assert the sizes/offsets.<br><br>> Another argument to keep the structure is that is has proven to be<br>> easily portable; and we should be very careful to change it.<br><br>I think the current structure has proven easily copied around and then not fixed and bugs lurking..<br>This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time.<br>Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem.<br><br> - Jay<br><br><br><br><br>> Date: Wed, 23 Apr 2008 23:32:43 +0200<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] naming conventions for split/composed interfaces?<br>> <br>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<br>> <br>> > Basically, I hate the idea of tangling together multiple machine-<br>> > dependent systems in the same files. Yes, it is verbose with<br>> > duplicated functionality, but it *is* separable. I can delete one set<br>> > of files without breaking builds on other targets. I hate the idea of<br>> > C wrappers even more!<br>> ><br>> > So, my position remains that while it is verbose having separate<br>> > target-specific directories, at least they are independent and isolated.<br>> ><br>> > I actually think your suggestion is much messier than the current situation!<br>> <br>> I agree with Tony here: we should keep the structure as simple and<br>> easily manageable as possible.<br>> <br>> While I understand your idea to join together files based on content<br>> (or, ultimately, on Unix history) we should keep in mind that a<br>> minimal amount of code does not always mean the minimal amount<br>> of maintenance costs, as the underlying systems evolve, too, and may<br>> (and will) do so in different directions. This may then require a<br>> different internal structure.<br>> <br>> So I like the idea of keeping different directories for different<br>> systems, even if there is some redundancy.<br>> <br>> Another argument to keep the structure is that is has proven to be<br>> easily portable; and we should be very careful to change it.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br></body>
</html>