Home
last modified time | relevance | path

Searched refs:CNAME (Results 1 – 25 of 28) sorted by relevance

12

/external/eigen/cmake/
DEigenTesting.cmake345 ei_get_compilerver_from_cxx_version_string("${eigen_cxx_compiler_version_string}" CNAME CVER)
346 set(${VAR} "${CNAME}-${CVER}")
355 macro(ei_get_compilerver_from_cxx_version_string VERSTRING CNAME CVER)
365 set(${CNAME} "llvm-g++")
367 set(${CNAME} "llvm-clang++")
369 set(${CNAME} "icpc")
371 set(${CNAME} "g++")
373 set(${CNAME} "_")
477 ei_get_compilerver_from_cxx_version_string(${STR} CNAME CVER)
478 if((NOT ${REFNAME} STREQUAL ${CNAME}) OR (NOT ${REFVER} STREQUAL ${CVER}))
[all …]
/external/chromium-trace/catapult/telemetry/third_party/webpagereplay/third_party/dns/
Drdatatype.py38 CNAME = 5 variable
100 'CNAME' : CNAME,
Dresolver.py108 if rdtype != dns.rdatatype.CNAME:
113 dns.rdatatype.CNAME)
/external/chromium-trace/catapult/telemetry/third_party/webpagereplay/third_party/dns/rdtypes/ANY/
DCNAME.py18 class CNAME(dns.rdtypes.nsbase.NSBase): class
/external/webrtc/webrtc/modules/rtp_rtcp/source/
Drtcp_receiver.h63 int32_t CNAME(uint32_t remoteSSRC, char cName[RTCP_CNAME_SIZE]) const;
Drtcp_receiver_unittest.cc454 EXPECT_EQ(0, rtcp_receiver_->CNAME(kSenderSsrc, cName)); in TEST_F()
466 EXPECT_EQ(0, rtcp_receiver_->CNAME(kSenderSsrc, cName)); in TEST_F()
473 EXPECT_EQ(-1, rtcp_receiver_->CNAME(kSenderSsrc, cName)); in TEST_F()
Drtp_rtcp_impl.cc511 return rtcp_receiver_.CNAME(remote_ssrc, c_name); in RemoteCNAME()
Drtcp_receiver.cc1427 int32_t RTCPReceiver::CNAME(uint32_t remoteSSRC, in CNAME() function in webrtc::RTCPReceiver
/external/avahi/docs/
DTODO90 * generate local CNAME responses
/external/dnsmasq/
DCHANGELOG.archive91 Fixed cacheing of CNAMEs. Previously, a CNAME which pointed
201 Re-vamped CNAME processing to cope with RFC 2317's use of
329 Fix bug in CNAME chasing code: One CNAME pointing
524 caching of RFC 2317 CNAME-PTR records.
1290 Fix rare crash associated with long DNS names and CNAME
1338 Fix interesting corner case in CNAME handling. This occurs
1339 when a CNAME has a target which "shadowed" by a name in
1340 /etc/hosts or from DHCP. Resolving the CNAME would sneak
1341 the upstream value of the CNAME's target into the cache,
1343 resolving the CNAME still gives the unshadowed value. This
[all …]
/external/dnsmasq/po/
Dfr.po659 msgid "bad CNAME"
660 msgstr "mauvais CNAME"
663 msgid "duplicate CNAME"
664 msgstr "ce CNAME existe d�ja"
Dpl.po643 msgid "bad CNAME"
644 msgstr "z�a CNAME"
647 msgid "duplicate CNAME"
648 msgstr "powt�rzona CNAME"
Dfi.po637 msgid "bad CNAME"
641 msgid "duplicate CNAME"
Dpt_BR.po637 msgid "bad CNAME"
641 msgid "duplicate CNAME"
Dit.po637 msgid "bad CNAME"
641 msgid "duplicate CNAME"
Des.po661 msgid "bad CNAME"
665 msgid "duplicate CNAME"
666 msgstr "CNAME duplicado"
Dde.po675 msgid "bad CNAME"
679 msgid "duplicate CNAME"
Did.po753 msgid "bad CNAME"
757 msgid "duplicate CNAME"
Dno.po660 msgid "bad CNAME"
664 msgid "duplicate CNAME"
Dro.po658 msgid "bad CNAME"
662 msgid "duplicate CNAME"
/external/c-ares/
DCHANGES34 o ares_parse_a_reply: fix CNAME response parsing
521 a CNAME record, this behaviour is defeated since the original query does
524 the CNAME.
/external/avahi/specs/
Ddraft-cheshire-dnsext-multicastdns-04.txt1848 programmatically-generated CNAME records. For example, if a responder
1852 resource records: A CNAME record "X CNAME Y", asserting that the
Ddraft-cheshire-dnsext-multicastdns-03.txt1848 programmatically-generated CNAME records. For example, if a responder
1852 resource records: A CNAME record "X CNAME Y", asserting that the
Ddraft-cheshire-dnsext-multicastdns-05.txt1966 programmatically-generated CNAME records. For example, if a responder
1970 resource records: A CNAME record "X CNAME Y", asserting that the
Ddraft-cheshire-dnsext-multicastdns-06.txt2302 generated CNAME records. For example, if a responder has an address
2306 A CNAME record "X CNAME Y", asserting that the requested name X

12