On Fri, Feb 09, 2001 at 12:16:13AM -0500, Chris Jepeway wrote:
> Seems like a red herring, though: simplest of all is
> guessing that it's switched off the file's version number,
> which is how other timescales for this format are selected.
>
> Sound reasonable? That is, does it make sense to
> say the timeunits for NetXray files with a version
> string of "002.001" should be 1193180.0? If so,
> I'll send patches. If not, please, as they say, advise.
That's what I was thinking - perhaps either 2.x, or maybe all Windows
Sniffer versions, use .838096 us rather than 1 us as the time stamp (I
no longer remember whether we determined that a 001.001 file had time
stamps in precise microsecond units or just that it definitely wasn't
milliseconds and seemed to be off by about a factor of 1000).
Can you feed a 1.1-format file, as written by Ethereal, to a Sniffer at
your client's site, and see whether it interprets time stamps the same
way that Ethereal does, or if it's off by a factor of, well, .838096 or
1.1193180, depending on how you look at it?
> And, while I'm at it, I have a couple coding style questions:
>
> How do folk feel about declaring functions inline? It's
> been done in a couple-three places already, but I don't
> see configure checking to see whether the compiler
> supports inline decls.
I tend not to use them, as
1) I'm not sure which C compilers support them
and
2) GDB, in my experience, doesn't handle them well.
As for 1), we've probably gotten away with it because <glib.h> checks
whether G_HAVE_INLINE is defined and, if not, tries to #define inline as
something that gives you inlines or, if it can't, defines it as nothing,
so that we adapt to what GLib thinks the compiler can handle with
whatever compiler was used when GLib was configured.
As for 2), at NetApp, stack traces tended to show the line in the inline
function where a crash occurred, which told you nothing about who
"called" the function; in an experiment here with a small test program,
GDB showed me the calling line, but not the actual line in the inline
function.
(Some of that may be the fault of the symbol table format (I don't
remember whether I saw the NetApp stack trace problems only on crash
dumps from our appliances - we don't currently use ELF as our object
file format - or also saw it from native ELF programs on, say, Solaris;
in any case, even if ELF can handle it, that's not the only object file
format we'd have to deal with, even if the Microsoft Visual C++ debugger
and symbol tables can handle it as well), and some of it may be that GDB
would have to be tweaked to understand that a given instruction belongs,
in some sense, to two source code lines.)
> Any problem with fleshing out the 64-bit support in
> wtap-int.h by adding pletohll() and htolell() macros?
No, as long as we cope with platforms where G_HAVE_GINT64 is *not*
defined - i.e., we should be able to compile even if you don't have
64-bit integer data types in the C compiler.
This may either require falling back on floating point or taking the
support routines from, say, libgcc (and supplying any missing ones -
GCC2 can generate inline code for a lot of 64-bit integer operations).
