search for: uintx_t

I'm in the same situation James is in and thus have the same bias but I'll +1 that comment nevertheless. I think I prefer using size_t or the uintX_t types where applicable. Only when I need a signed value do I use one. On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Maybe it's just because I work in code around the binary file formats > almost exclusively, but unsigned (or more...

...gt; > > On Mon, Jun 10, 2019, 7:16 PM Jake Ehrlich via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm in the same situation James is in and thus have the same bias but >> I'll +1 that comment nevertheless. I think I prefer using size_t or the >> uintX_t types where applicable. Only when I need a signed value do I use >> one. >> > > +1 to prefering unsigned types. > I'd appreciate if you guys could provide rational that address the extensive arguments and opinion provided in the C++ community that I tried to summarize in t...

...PM Jake Ehrlich via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> I'm in the same situation James is in and thus have the same bias but >>>> I'll +1 that comment nevertheless. I think I prefer using size_t or the >>>> uintX_t types where applicable. Only when I need a signed value do I use >>>> one. >>>> >>> >>> +1 to prefering unsigned types. >>> >> >> I'd appreciate if you guys could provide rational that address the >> extensive arguments and op...

...e user should provide a minimal replacement header. I've also just updated the commemt above the #include <stdint.h> to say: /* If your compiler does not provide <stdint.h> you should provide a replacement * which has suitable replacements for the following intX_T and uintX_t types. * For example: * http://msinttypes.googlecode.com/svn/trunk/stdint.h * http://www.azillionmonkeys.com/qed/pstdint.h */ Is this not an acceptable solution? Its kind of neater and MSVC really is the only compiler I know of that doesn't have <stdint.h>. > Al...

...gt;>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> I'm in the same situation James is in and thus have the same bias but >>>>>> I'll +1 that comment nevertheless. I think I prefer using size_t or the >>>>>> uintX_t types where applicable. Only when I need a signed value do I use >>>>>> one. >>>>>> >>>>> >>>>> +1 to prefering unsigned types. >>>>> >>>> >>>> I'd appreciate if you guys could provide ratio...

...mic relocation is needed. for (OutputSectionBase<ELFT> *Sec : OutputSections) { Sec->forEachInputSection([&](InputSectionBase<ELFT> *S) { if (auto *IS = dyn_cast<InputSection<ELFT>>(S)) { // Set OutSecOff so that scanRelocations can use it. uintX_t Off = alignTo(Sec->getSize(), S->Alignment); IS->OutSecOff = Off; scanRelocations(*IS); // Now that scan relocs possibly changed the size, update the offset. Sec->setSize(Off + S->getSize()); } else if (auto *EH = dyn_cast<EhInputSection<...

Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev <llvm-dev at lists.llvm.org>: > I'd prefer us to have something neater than static_cast<int> for the > loop problem before we made that change. Perhaps add an ssize (or > equivalent) method to all of our internal data structures? They're a > lot more common than std::* containers. +1 Since C++20

On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce

...--git a/ELF/SyntheticSections.h b/ELF/SyntheticSections.h index a1190d2..9f99931 100644 --- a/ELF/SyntheticSections.h +++ b/ELF/SyntheticSections.h @@ -290,8 +290,8 @@ public: uint32_t Type; -private: SymbolBody *Sym; +private: const InputSectionBase<ELFT> *InputSec = nullptr; uintX_t OffsetInSec; bool UseSymVA;

Thanks, Erik. This is the delta that should fix everything up. I hope that #include "share/compat.h" is acceptable from the test_streams binary. If not, you can probably change it to FLAC/ordinals.h instead Also don't forget to commit my earlier VERSION="1.3.0" patch. You can add the "pre1" in a normal text editor without risk. I didn't include those

...mail */ > /* #undef SENDMAIL_VERSION_B */ > > /* subversion of Sendmail */ > /* #undef SENDMAIL_VERSION_C */ > > /* Define to 1 if the `setpgrp' function takes no argument. */ > #define SETPGRP_VOID 1 > > #if 0 > /* lets assume system has proper stdint that defines uintX_t. */ > /* The number of bytes in type int */ > /* #define SIZEOF_INT 4 */ > > /* The number of bytes in type long */ > #define SIZEOF_LONG 8 > > /* The number of bytes in type long long */ > #define SIZEOF_LONG_LONG 8 > > /* The number of bytes in type short */ > #de...

Chris Lattner wrote: > One way to do this is to add a "cut down" version of the app to the > test suite. I disabled optional features in clamav-config.h > >> 2. GPL license. Chris? > > Any open source license that allows unrestricted redistribution is > fine in llvm-test Ok, I have created a script that automatically checks out ClamAV 0.92-stable source code

On Mon, 17 Dec 2007, Evan Cheng wrote: > We always welcome more tests. But it looks like there are two issues > here. > > 1. The autoconf requirement. Is it possible to get one configuration > working without the need for autoconf? One way to do this is to add a "cut down" version of the app to the test suite. > 2. GPL license. Chris? Any open source license that